Bulk monitors guide #1338
Bulk monitors guide #1338
Conversation
Co-authored-by: Susa Tünker <[email protected]>
Co-authored-by: Susa Tünker <[email protected]>
Co-authored-by: Stefan Judis <[email protected]>
Co-authored-by: Stefan Judis <[email protected]>
Co-authored-by: Stefan Judis <[email protected]>
Co-authored-by: Stefan Judis <[email protected]>
serverless-mom
requested review from
stefanjudis,
Dgiordano33,
guolau and
sujaya-sys
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Co-authored-by: Stefan Judis <[email protected]>
Co-authored-by: Stefan Judis <[email protected]>
Co-authored-by: Stefan Judis <[email protected]>
…om into claudeCodeGuide
|
There was a problem hiding this comment.
Nice, short, and simple demonstration of what the CLI is capable of. The sitemap example is pretty neat!
I'd agree with Dan that this is somewhat hard to follow. Especially for users who are new to Checkly and MaC, I can see them being somewhat lost or intimidated. I think it'd be easier to follow if it were broken down more into steps, ex:
- First, we need URLs to monitor. Here is a list of URLs, or a JSON file, or parse your sitemap!
- Next, let's create the URL monitor construct. Here's what these properties mean, and here are links to the documentation.
- Here is what the completed code looks like
- Then we deploy. Now all the monitors are in Checkly
- Next steps/conclusion
Of course, just my 2 cents.
| title: Monitor 500 pages in 2 minutes with Checkly | ||
| displayTitle: Monitor 500 pages in 2 minutes with Checkly | ||
| description: >- | ||
| By leveraging arrays, sitemap parsing, and dynamic monitor creation, you can ensure comprehensive coverage of your website, API routes, and third-party services—all from a single configuration file. |
There was a problem hiding this comment.
Nit: should we remove the part about third-party services? From a support POV, we recommend not monitoring sites you don't control (you can't fix it if it goes down, it can change at any moment, and third-parties have every right to block this kind of traffic)
|
|
||
| ## Next Steps: Grouping, and More Advanced Checks | ||
|
|
||
| With all of our monitors managed with a single file, we can update their configuration just by changing the values in the `new UrlMonitor` block above. However, as we have more detailed and nuanced monitoring, it would be nice to have a single place to manage configuration for timing, alerting, and notification channels for a group of checks. All of that is possible with Checkly Groups. |
There was a problem hiding this comment.
Nit: Might be good to add a link to the groups doc here. https://www.checklyhq.com/docs/groups/
|
|
||
| If these look correct, you’re ready to run `npx checkly deploy` and create your new monitors! | ||
|
|
||
| ## Next Steps: Grouping, and More Advanced Checks |
There was a problem hiding this comment.
Would it be worth mentioning the global config file here as well?
| @@ -10,6 +10,7 @@ menu: | |||
|
|
|||
There was a problem hiding this comment.
Nice to have: A short intro sentence briefly summarizing the use case behind this. For example "When working with AI IDEs, you can provide them with context on Checkly, which enables automated generation of Checkly constructs, helping you speed up your monitor creation workflow."
Also: As a reader it'll be interesting to know if I can chose from one of the options listed below or if its recommended to provide as much context as possible e.g. reference the docs site + download the custom rules.
| }) | ||
| ``` | ||
|
|
||
| This takes an array of URLs and creates a new monitor with a unique ID and name. We can test run these tests with `npx checkly test` and both monitors will run in our CLI’s default region. |
There was a problem hiding this comment.
Maybe I'm missing something but its unclear to me what to do with this file. Where does it live? Where do the generated monitors land? How can I execute it?
|
|
||
| ## Next Steps: Grouping, and More Advanced Checks | ||
|
|
||
| With all of our monitors managed with a single file, we can update their configuration just by changing the values in the `new UrlMonitor` block above. However, as we have more detailed and nuanced monitoring, it would be nice to have a single place to manage configuration for timing, alerting, and notification channels for a group of checks. All of that is possible with Checkly Groups. |
There was a problem hiding this comment.
I agree with Laura, we should either link to the groups construct here or add an example code snippet below. Otherwise its a little unclear how to act on this.
| @@ -0,0 +1,204 @@ | |||
| --- | |||
| title: Monitor 500 pages in 2 minutes with Checkly | |||
| displayTitle: Monitor 500 pages in 2 minutes with Checkly | |||
There was a problem hiding this comment.
I found the headline slightly misleading when reading it for the first time. "Creating monitors" would be more tangible if we want to be explicit.
| const urlPath = new URL(url).pathname.replace(/\//g, '-').replace(/^-+|-+$/g, '') || 'root' | ||
| ``` | ||
|
|
||
| Depending on how you format your input array, this cleanup step may be unnecessary. |
There was a problem hiding this comment.
Would be helpful to provide more context on what this cleanup step does so I can understand whether I need it or not.
This version is not current, the updated version of this article is on Notion
Affected Components
I'm not fully in love with the formatting of the middle section, where I comment on individual code lines, maybe I should just rewrite as being comments inside the code snippet. LMK what you think.